The basic premise here is that we want to be able to get a broader overview of what is happening in the system by looking at data across subsystems (alerts, operations, etc) at once. For instance, instead of looking at alerts on each of my JBossAS resources, I should be able to view all alerts across the system (and then potentially filter them). Instead of looking at the results of operations for a single resource or compatible group, I want to see all of my operations at once (and then potentially filter them).
The dashboard attempts to provide this functionality, but does not scale well to very larger inventories where you'll generally need to sort through vast quantities of data to find precisely what you're looking for. The dashboard doesn't providing sorting, pagination, or searching of the results - it only gives the "last 10 operations executed" or "5 most recent alerts". Thus, in order to make this useful for users, we want to provide them with a way to quickly navigate through the data from each subsystem, which means 'search'.
However, instead of spending time writing custom search interfaces for each subsystem of data we want to sift through, a better approach might be to provide a way to somehow automatically build up a search interface. The requirements for such a tool are below. A mock-up for what the dynamic interface for search alerts would look like (with saved search patterns) is on the right.
alert history
operation history
availability history - is this verging on reporting?
problem resource
events history
resource configuration history
deployments / package changes
entry point method
tab approach
when we get too many tabs, then make them multi-layered?
how to order the tabs? - wouldn't necessarily map to the tab layout for resources...would it?
simple, alpha-ordered select list of different views <-- simpler
extensible dynamic search interface
interface that provides a dynamic list of search criteria
each criteria can then provide a list of applicable choices
applicable choices should be wrt the search criteria
show counts next to each criteria choice
allow counts to be toggled
suppress display of 0-count choices
example: alerts definitions
allow search on priority, which has possible values of LOW, MEDIUM, HIGH
but if there aren't any LOW alerts, values will only be MEDIUM and HIGH
display will show counts parenthetically: MEDIUM (34), HIGH (56) in the drop-down
special base component
will provide common functionality across all subsystem views
will expose a list of shared criteria and applicable criteria choices
common criteria list
resource type: type name, category (platform, server, service)
resource group name
resource name
resource's current availability (UP / DOWN)
time period - this is a shared criteria, but needs to be implemented differently by each subsystem view (see "date picker supports two modes" below)
sticky navigation: allow navigation between different subsystem views via "entry point method", but make the current options within the "common criteria list" sticky; this will allow navigation back and forth across the subsystems and will keep the context consistent for data correlation purposes
query generation
generate the table data query from the selected criteria choices
generate the list of criteria choices for unselected criteria off of the results from the main query
count queries off of each groupby to generate item counts
example: problem resources
assume availabilityType search option already selected, choice was DOWN
allow search on resourceType field too, but limit the values in drop-down to types that are DOWN
display will show counts of only DOWN'ed types, parenthetically: JBossAS Server (2), IIS (1)
metadata
allow the searchable fields to be specified through a simple descriptor
enables search interface to be built up while requiring little to no coding
allow the field name to be customized, i.e. does not have to match the entity field name being searched on
allow the renderer to be specified through the descriptor (combobox, input text, date picker, checkbox)
combobox should be multi-select
input text render will additionally support auto-suggest features (richfaces supports this)
allow multiple instances of auto-suggest input text fields to mirror the multi-select capabilities of combobox inputs
little "plus" icon to add another one somewhere that ajax-adds the new field
date picker supports two modes (do we need an explicit 'simple' vs 'advanced' option, or is that a better way to display this choice)
last X units in Y period (e.g, last 5 days, last 8 hours, etc)
combination of before this date and/or after that date, each can be N/A
expression processing
each different search / filter param will be AND'ed together
multiple instances of the same search / filter param (multi-select combobox, multiple instances of auto-suggest input text) will be OR'ed together
allow developer to choose the search field ordering for consistency of rendering
ui considerations
rendering based on ui data from the metadata
consistent field ordering
integration with rich table component, in particular the DataModel
this enables us to add dynamically rendered search interfaces to ANY tabular display
javascripty expand/collapse of the search interface
automatically store last search - this is an extension to the already auto-persisted pagination/sorting stuff
support ability to save search patterns
searches are associated with tabular display, so will hang off of PageControl too
selection of saved search pattern populates rest of UI panel with correct options
search button needs to be clicked separately?
this allows for you to select various saved searches, and quickly see what they are
e.g. HIGH alerts for the last 7 days or RESTART operations on JBAS resources in the last 4 hrs
saved searches should have its own rollup window
display result counts next to each saved search
toggle for count display
restrict the display of result set data so that the interface has a maximum time for rendering
e.g., some result set for combobox is huge (~1000), if count > 20 convert to input text field and log WARNing
either that or cap the list at 20, and print "..." after that?
pivoted views
supported views
subsystem data view - default audit entries shown in the table
resource view - generic resource composite table with counts of subsystem data audit entries that match the given search / filter params
resource group view - generic resource group composite table with counts of resources & subsystem data audit entries that match the given search (i.e., any resourceGroup containing any resource containing any data that matches the filter, group by resourceGroup and count the authz-aware resources that have data matching the filter, as well as the raw counts of the data that match that filter by group)
interface layout
flat - use composites to show the view, and counts to show the grouped values
hierarchical - allow the user to choose a permutation of (data,resource,group)
first item in list is the primary display
each item in the primary display is an ajax-y, expandable, nested table (richfaces supports this naturally) - problem here MIGHT be how to effectively search large nested tables (i say MIGHT because i wonder if our datatable extensions would "just work" to give you sortable, paginated nested data)
enhanced support for cluster views
if i wanted to see all alerts that are on ANY resource in some cluster...
create mixed, recursive group on the fly? (at the time the search is triggered)
group definition enhancement: mechanism to create both compatible (cluster) and mixed recursive groups at the same time, instead of one or the other
problem with this solution is that the group membership could get stale, and would need explicit recalculation by some end user
flatten the resource hierarchy - mechanism that enables a single, non-recursive query to gather ALL descendants of a resource or resourceGroup
this would be auto-calculating, but would need tight integration with inventory operations (commit / manualAdd / createNew, uninventory, delete) to make sure it was kept up to date (though we've done similar things like this with auto-creating alert templates, so it's not like this strategy is ground-breaking)
authorization would change: instead of explicit/implicit it would be more like hierarchical/unrolled. if recursive bit is set: subject-role-group-unrolled. if recursive bit is NOT set: subject-role-group-hierarchical (this is what we use today).
the benefit of this is that recursive groups have practical NO computation cost, because the hierarchical is already flattened
furthermore, it would enable us to provide a checkbox in the dynamic search UI to "include children" resources in the search; if it's selected then we follow the "unrolled" authz path; if not, we follow the "hierarchical" path; since the query is built up on the fly anyway, it would be easily to switch in between these two models
permissions
need to support admin versus non-admin queries for each
list of criteria might be different depending on user too (to allow admin to search on more than a user)
saved search portlet (the ultimate eat-your-own-dogfood)
use the dynamic search interface to allow people to search their saved search patterns
admin users can search all paterns, non-admin users can only see their own
criteria:
user (who does this pattern belong to [only applicable to admins])
pattern name
entity type / view
clicking a saved search in the table will wisk the user to the appropriate view within the application
export
serialization options: comma-delimited, excel spreadsheet, rss/atom feed
data selection options: ALL, "the current view"
all data selection options should respect the current sort/pagination params
shared search patterns with others in the system (like how you can promote a JIRA filter to be exposed to specific JIRA groups)